The first indicator that ODB-II is appropriate is a realization that relational databases cannot do the job. The usual reason for this is that the data is either too complex or too variable to represent naturally in tabular form.
Complexity may reveal itself by the presence of multimedia information. At an information modeling level the problem is often the existence of a hierarchy, network or graph in the data being modeled. Another clue is the need to deal with queries that involve some computation:
"What is the best way of getting to Barcelona?";
"Is this piston strong enough?";
"From which buildings will this road be visible?".
Variability may reveal itself in a large number of special cases that need to be handled, for example, a company may have many different bonus schemes for different categories of employee. It may also arise because the same application is sold to many different organizations who all have slightly different requirements. Or it may arise because the pace of change is very rapid.
Because ODB-II incorporates the relational model of data as a subset, there is no sacrifice of functionality involved in using it. Relational products have acquired a raft of supporting tools which no object database can yet match, but the expressive power of the ODQL language will often compensate for this.
ODB-II is engineered to support enterprise applications: those where there is potentially a large population of geographically dispersed users, with a wide and changing variety of needs to access the same information in different ways, and where the data itself is valuable to the enterprise and is probably long-lived. It is capable of handling other requirements (for example, simple enterprise data or complex personal data) but it is not optimized for those situations.
Leading Edge Features of ODB-II
Object Database Query Language
Current Implementations of ODB-II